REMARKS 



This paper is responsive to the Office Action mailed April 16, 2007. 

Claim 29 was amended (solely for formal reasons not related to patentability), to address 
the Examiner's formal concerns. As the Examiner can see, amended claim 29 does not include 
any language that may be mistaken for an improper Markush group - which is most often 
associated with the chemical arts. 

In the Office Action, claims 28-36 and 40-47 were rejected as being anticipated by Cross. 
Reconsideration and withdrawal of these rejections are respectfully requested. 

Claim 1 recites: 

28. (Original) Computer-implemented and Internet-based method of 
disputing an invoice from a vendor to a customer, comprising the steps of: 

accessing a database record corresponding to the invoice to be disputed over a 
Web site of the vendor; 

selecting a reason code for the dispute along with an identification of a disputed 
amount; 

validating a Credit Memo Request incorporating the selected reason code and 
the disputed amount to create a pending Credit Memo Request; 

causing the Credit Memo Request to be sent to and routed through at least one 
of a selected process for the selected reason code, a selected hierarchy of persons 
empowered to approve Credit Memo Request incorporating the selected reason 
code and a primary approver for the selected reason code; 

receiving a notification upon approval or rejection of the pending Credit Memo 
Request, the disputed amount being automatically credited to the disputed 
invoice when the pending Credit Memo Request is approved. 

As can be seen, the pending claim requires that a Credit Memo Request incorporating the 
selected reason code and the disputed amount to create a pending Credit Memo Request be 
validated, and sent through a selected process, a selected hierarchy and/or a primary approver. 
Within the context of anticipation, if an applied reference does not include one or more claim 
elements (steps, in this case), the anticipation rejection fails and must be withdrawn. 
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In the present case, Cross (for example) does not teach any manner of a credit memo or the 
validation of a credit memo request. Cross also does not teach that a credit memo is sent through a 
selected process, a selected hierarchy and/or a primary approver, as required by claim 1. The term 
"credit memo", a standard term in the Accounts Receivable (AR) field, is not even present in the 
patent. This is because Cross does not use the credit memo mechanism. 

The entire Cross patent is parsed below. Cross teaches for a second telecom carrier (e.g., 
local, small telecom) to send a bill to a first telecom carrier (e.g., Big Telecom) for use of its lines 
and capacity (see Col. 4, lines 35-55) Col. 56-67 details how such bill may be submitted. The 
billing info in the bill is then converted to a suitable RDMS format, as taught in Cross (see Col. 5, 
lines 11-26). An automatic validation module 18 retrieves the charges and performs a number of 
validity checks thereon (see Col. 5, lines 33-42). Any discrepancies uncovered as a result of the 
validity checks are sent to the dispute-tracking module 20, which allows the user to review the 
charges made by the vendor. The user may approve or disapprove of the invoice associated with 
the discrepancy (see Col. 5, line 43-56). The balance of Column 5 and Column 6 provides 
additional details on the aforementioned steps. For example details the change of format of the 
original bill data, and provides additional details concerning the validity checks, which check the 
bill for corrupted data, load the data into a production database, perform additional integrity checks 
and parse the data into individual billing entries (see Col 6, lines 19-49). Beginning at Col. 6, line 
66, the analysis of the bill data begins with a comparison of the bill data to pre-stored reference 
charges and reference information. Reason codes are introduced at Col. 7, lines 18-24. The 
automatic validation module then generates reports, including a dispute report, as taught (see Col. 
7, lines 37-45). The analysis of the billed charges are further detailed beginning at Col. 7, line 46 
and includes a discussion of circuit charges, which are charges for use of a telecom circuit; see Col 
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8, lines 1-19. Beginning at Col. 8, line 20, specific discrepancies are discussed. The dispute 
tracking module is disclosed at Col. 8, beginning at line 35, and allows the user to query the 
database for disputable items. The dispute tracking module also generates the discrepancy report, 
as taught (see Col. 8, line 40). A Graphical User Interface (GUI) that facilitates the generation of 
the discrepancy report is discussed beginning at Col. 8, line 46. 

Beginning at Col. 9, line 3, Cross teaches that the discrepancy report may be hierarchical in 
nature, with subtopics of constituent nodes of the report being clickable to dynamically reveal 
additional information. Col. 9, lines 10-13 state that the reason code for the disputed amount may 
be revealed in that manner. Col. 9, lines 19-34 teach that the user may search the database for 
disputed amounts by, e.g., disputed amount, vendor, etc. 

Fig. 9, described beginning at Col. 9, line 35, shows the steps performed by the automatic 
tracking module that Cross uses to generate the dispute report. The report may include a 
description of the dispute and the user can display modify, review or delete the dispute report, as 
taught (see Col. 9, lines 5 1-67). Col. 10, lines 1-12 teach that a dispute report may be "closed" once 
the dispute has been resolved, which may be indicated on the dispute report. Once the billed 
charges have been processed, the billed charges may be combined into invoices for the different 
vendors and the system user can then approve or disapprove the invoices, utilizing a bill review 
and approval module, as taught (see Col. 10, lines 13-28). Before an invoice can be approved, it 
must be reviewed by a system user (see Col. 10, lines 29-31). Various GUI elements are discussed 
from Col. 10, line 31-61. Beginning at Col. 10, line 62, Cross teaches that invoices are associated 
with dispute reports, by dragging and dropping invoice icons onto dispute report icons (see Col. 11, 
lines 1-14). Beginning at Col. 11, line 15, Cross teaches how users can access the production 
database and have requested information displayed. The concept of "short paying" (paying less 
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than the full amount of the bill) is discussed beginning at Col. 11, line 36. Beginning at Col. 11, 
line 43, Cross discusses the possible reasons for rejecting a billed charge and that a rejected billed 
charge is transmitted to the automatic validation module "for further review" (see Col. 11, lines 45- 
50). Various other aspects of Cross's GUI (pull-down menus, etc) are discussed beginning at Col. 

1 1, line 51. Searching through disputes is discussed beginning at Col. 12, line 7. An output module 
is taught at Col. 12, lines 17-26 and the detailed operation thereof is described at Col. 12, line 27- 
57. Finally, the ability to print the dispute report is discussed, along with the Cross's methodology 
for authorizing the payment of the billed charges. After the standard boilerplate language at Col. 

12, lines 57-67 are Cross's claims and the end of the patent. 

Therefore, it is respectfully submitted that Cross fails to teach a credit memo or the 
validation of a credit memo request, as required by the claim. Cross also does not teach that a 
credit memo is sent through a selected process, a selected hierarchy and/or a primary approver, as 
also required by claim 1. In particular, the passages identified by the Office as teaching the claimed 
validating causing and receiving steps do not teach anything of the sort, as Cross does not even 
mention credit memos or what, if anything, to do with them. 

Independent claim 40 recites: 

a Web site, the Web site being controlled by the vendor and accessible by the 
computer, the Web site being configured to allow a customer using the computer 
to remotely access the invoice and to dispute the invoice by: 

selecting a reason code for the dispute and at least a disputed amount; 

validating a Credit Memo Request incorporating the selected reason code and 
the disputed amount to create a pending Credit Memo Request, and 

causing the Credit Memo Request to be sent to be processed through a workflow 
engine to send and route the Credit Memo Request through at least one of a 
selected process for the selected reason code, a selected hierarchy of persons 
empowered to approve Credit Memo Request incorporating the selected reason 
code and a primary approver for the selected reason code. 
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At the outset, Cross does not teach any method that would allow the 1 st vendor (Big 
Telecom) to access a web site of the 2 vendor (smaller, local telecom) to remotely access the 
invoice issued by the 2 nd vendor and to dispute it. In Cross, the 2 nd vendor sends bills to the first 
vendor and the first vendor carries out Cross's method to determine which bills to pay in full, 
which bills to short pay and which bills to dispute. For the reasons developed above with respect to 
claim 1, Cross does not teach either the validating or the causing steps. Indeed, Cross does not even 
teach any method that involves credit memos, as demonstrated above. For example, claim 40 
recites: 

a Web site, the Web site being controlled by the vendor and accessible by the 
computer, the Web site being configured to allow a customer using the computer 
to remotely access the invoice and to dispute the invoice 

The Office asserts that such is taught at Cross, Col. 11, line 11-21. This passage is 
sufficiently short as to be readily reproducible herein below: 

The detailed operation of the bill review and approval 15 
module is disclosed in FIG. 12. After a user has accessed the 
bill review and approval module, the system user requests 
that particular billed charge be retrieved from the database. 
After the request is input through the screen display, the 
billed charges are retrieved from the production database 20 
and displayed for the user. As was discussed above, all 

As may be seen, this passage does not teach any Web site, and much less a Web site having 
the claimed characteristics and functionalities. Likewise, the passages purported to include 
teachings related to Credit Memos are silent on that issue as well. 

In view of the foregoing, it is respectfully requested that the anticipatory rejection of the 
claims be reconsidered and withdrawn. The same is, therefore, respectfully requested. 
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Applicants believe that this application is now in condition for allowance. If any unresolved 
issues remain, please contact the undersigned attorney of record at the telephone number indicated 
below and whatever is necessary to resolve such issues will be done at once. 



YOUNG LAW FIRM, P.C. 
4370 Alpine Rd., Ste. 106 
Portola Valley, CA 94028 
Tel.: (650)851-7210 
Fax: (650)851-7232 
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Respectfully submitted, 



Date: 



June 7. 2007 



By: 




Alan W. Young 
Attorney for Applicants 
Registration No. 37,970 
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